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Abstract 

The  lengthening  lifetimes  of  intelligent  systems,  and 
the  desire  to  share  or  re-use  knowledge  bases,  has  created 
within  the  AI  community  the  need  for  application- 
independent  knowledge  representation  systems.  The 
Loom  system  being  developed  at  1SI  represents  the  latest 
in  a  series  of  "classification-based"  knowledge  represen¬ 
tation  systems  developed  to  meet  this  need.1  In  Loom, 
the  traditional  single-classifier  architecture  is  replaced  by 
one  containing  a  collection  of  classifiers  which  exhibit  in¬ 
creasingly  powerful  inference  capabilities.  This  paper 
describes  the  knowledge  representation  language 
developed  for  the  Loom  system. 

1.  Introduction 

Loom2  represents  a  recent  entry  into  the  KL-ONE 
(Brachman  and  Schmolze  85)  family  of  knowledge 
representation  systems.  Loom  directly  succeeds  the  NIKL 
system  [Schmolze  and  Lipkis  83,  Moser  83)  developed 
jointly  by  ISI  and  BBN.  During  NIKL’s  lifetime,  the 
NIKL  user  community  produced  a  rather  extensive  list  of 
extensions  that  they  wished  to  see  in  future  versions  of 
NIKL  [Kaczmarek  86],  Loom's  designers  determined  that 
these  needs  could  best  be  achieved  by  redesigning  and 
reimplementing  NIKL.  The  result  is  a  nore  flexible  ar¬ 
chitecture  which  preserves  the  strengths  of  the  original 
NIKL  while  admitting  some  i.-w  and  powerful  forms  of 
reasoning. 

*Tliu  research  is  supported  by  the  Defense  Advanced  Research 
Piojects  Agency  under  Contract  MDA803-81-C-0335  Views  and 
conclusions  contained  in  this  paper  are  the  authors'  and  should  not 
be  interpreted  as  representing  the  official  opinion  of  DARPA,  the 
1  s  (hoerrunent  or  any  person  or  aeency  connected  with  them 
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Loom's  architecture  strongly  reflects  the  view  that 
the  variety  of  inferences  provided  by  a  comprehensive 
knowledge  representation  system  can  best  be  performed 
by  a  well-integrated  collection  of  specialized  reasoning 
components,  rather  than  by  a  single,  general-purpose 
reasoner.  KL-ONE-atyle  systems  (e.g.,  KL-ONE,  KL- 
TWO  (Vilain  85),  KRYPTON  (Brachman,  Pikes,  and 
Levesque  83),  and  BACK  (von  Luck  87])  have  tradition¬ 
ally  divided  their  knowledge  space  into  two  partitions, 
called  the  "Terminological  Box"  and  the  "Assertions! 
Box",  and  have  utilized  two  distinct  reasonere 
(terminological  and  assertional)  to  carry  out  their  in¬ 
ferences.  Loom's  principle  architectural  contribution  is 
to  introduce  two  additional  partitions  (the  "Universal 
Box"  and  the  "Default  Box"),  each  having  its  own  as¬ 
sociated  reasoning  component. 

Complementing  this  increase  in  the  number  of 
domain-independent  reasoners  embedded  in  the  system 
architecture  is  a  growing  library  of  domain-specific, 
"narrow-coverage"  reasoners.  Currently  these  include 
facilities  for  computing  or  reasoning  about  transitive  rela¬ 
tions,  sets,  intervals,  and  some  elementary  forms  of 
numeric  reasoning.  These  reasoners  esn  be  invoked  in¬ 
dependently,  or  called  by  the  broad-coverage  reasoners. 

The  trick  in  integrating  this  collection  of  reasoners 
is  to  develop  a  language  for  expressing  knowledge  which 
emphasizes  the  overall  coherence  and  uniformity  of  the 
knowledge  structures.  Loom  accomplishes  this  goal  by 
building  on  the  "concept-centered"  view  of  knowledge 
employed  in  KL-ONE  (and  NIKL).  Accordingly,  all 
universal  and  default  knowledge  is  attached  to  specific 


sets  of  threads  or  yarns  to 


concepts.  In  a  similar  vein,  sets,  intervals,  and  relations 
(including  transitive  and  composite  relations)  are  all  real¬ 
ized  as  specialized  forms  of  concepts  --  their  definitions 
share  a  uniform  syntax,  and  each  of  them  has  its  own 
sublattice  within  the  concept  taxonomy. 


This  paper  introduces  the  syntax  and  semantics  of 
that  portion  of  the  Loom  knowledge  representation  lan¬ 
guage  which  represents  meta-level  knowledge.  We  in¬ 
clude  discussions  on  some  of  the  types  of  inference  which 
can  be  performed  by  the  Loom  system.  We  begin  by 
defining  the  four  broad  types  of  knowledge  managed  by 
the  Loom  system,  and  then  discuss  each  of  the  "Boxes" 
devoted  to  representing  meta-level  knowledge.  The  ap¬ 
pendices  include  the  knowledge  bases  used  to  illustrate 
examples  of  Loom  syntax.  A  longer  version  of  this  paper 
(Mac  Gregor  87|  contains  a  complete  definition  of  the 
Loom  system. 


2.  Boxes 


In  order  to  accurately  define  concepts  and  relations 
in  Loom,  it  is  necessary  to  have  an  understanding  of  how 
Loom  treats  various  "kinds"  of  knowledge  within  the  sys¬ 
tem.  Loom  partitions  its  knowledge  space  into  four 
"Boxes",  called  the  Terminological,  Uniyersal,  Default, 
and  Asseriional  Boxes.  This  section  presents  a  brief 
characterization  of  each  of  these  four  kinds  of  knowledge. 
Later  sections  will  present  specifics  on  the  expressive  fea¬ 


tures  available  with  each  of  the  Loom  boxes. 


Definitions  within  the  "Terminological  Box"  (TBox) 
serve  to  define  the  "terms"  in  our  knowledge  represen¬ 
tation  scheme  (  [Brachman.  Fikes,  and  Levesque  83]  con¬ 
tains  a  good  discussion  of  w  hat  kind  of  knowledge  is  con¬ 
sidered  to  be  "terminological").  A  TBox  definition  yields 
a  set  of  necessary  and  sufficient  conditions  for  recogniz¬ 
ing  an  instance  of  some  concept.  Within  Ixxam,  the  or¬ 
ganization  (classification)  of  concepts  is  based  strictly  on 
the  terminological  knowledge  available  to  the  system. 


The  "Universal"  Box  (UBox)  widens  the  scope  of 
things  we  can  say  about  (generic)  concepts  to  include  cer¬ 
tain  forms  of  knowledge  about  the  "real  world".  In  the 
UBox  we  can  attach  necessary  conditions  to  a  concept 
definition.  For  example,  we  can  stale  that  "live-persons 
necessarily  have  heads",  i.e., 

Vx[Live— Person(x)  —  By  head(x,  y)]. 


In  the  UBox  we  can  also  state  conditions  which  are  suf¬ 


ficient,  but  not  necessary  to  recognize  an  instance  of  a 
concept.  For  example,  we  can  say  that  "all  featherless 
bipeds  are  human",  i.e., 


'ix\Ftatherltta—Biped(x)  — *  //umnn(r)|. 


A  second,  more  powerful  classifier  is  associated  with 


the  UBox.  The  UBox  classifier  makes  its  inferences 


(classifications)  on  the  basis  of  combined  TBox  and  UBox 
knowledge. 


The  "Default"  Box  is  the  proper  location  for 
representing  "assumptions"  or  "default  knowledge".  For 
example,  in  it  we  can  state  such  things  as  default  values: 
"If  nothing  has  been  asserted  about  the  color  of  some 
elephant  x,  make  the  assumption  ’color(x  Grey)'."  We 
can  also  state  some  limited  forms  of  closed-world  assump¬ 
tions:3  "If  some  paper  P  has  K  authors,  assume  that  it 
has  only  K  authors." 


The  knowledge  represented  in  the  Default  Box  is 
used  to  make  some  very  limited  types  of  inferences 
during  the  process  of  realization.  A  full-blown  use  of 
default  knowledge  would  seem  to  require  the  inclusion  of 
a  non-monotonic  reasoning  capability  into  Loom.  This  is 
beyond  the  scope  of  our  current  effort. 


The  Asseriional  Box  (ABox)  is  the  repository  for 
assertions  about  individuals.  For  example,  we  might 


’’By  default, the  Allot  issiuue 


B 


Mr 


i.y 

i 

W  - 

i 


m 


W 


ix*. 

1 
liVt 


Iw 

Icy 

y. 


place  in  the  ABox  the  assertion  that  Clyde  is  a  white 
elephant  by  making  the  assertions: 


(assert  (Elephant  Clyde)  (color  Clyde  white)) . 

The  effect  of  these  assertions  is  to  create  an  instance  in 


the  ABox  of  the  concept  Elephant  (unless  Clyde  already 
exists  in  the  ABox)  and  to  assign  to  the  color  role  of  the 
object  Clyde  the  value  White. 


Loom  hxs  extended  NIKL's  terminological  language 
CNIIvL  Robins  86j  to  include  expressions  of  universal 
and  default  knowledge.  We  believe  that  it  is  beneficial  to 
associate  each  fragment  of  universal  or  default  knowledge 
with  a  particular  concept:  thus,  we  have  chosen  to  extend 
the  syntax  of  the  original  dafconcapt  (and  dsfrslatlon) 
primitives,  rather  than  to  add  new  (top-level)  constructs 
to  the  terminological  language.  The  Engines  and  Cars 
knowledge  base  in  Figure  A-l  illustrates  some  Loom  con¬ 
cept  declarations.  The  original  CNIKL  definition  of  a 
concept  serves  as  its  definitional  component.  An 
"axioms"  clause  states  universal  knowledge  about  a  con¬ 
cept.  while  a  "defaults"  clause  states  default  knowledge. 


Engineering  Note: 

Our  introduction  of  a  new  type  of  reasoner  (the 
UBox  classifier)  puts  us  in  line  with  what  we  see  as  a 
long-range  trend  towards  knowledge  representation  ar¬ 
chitectures  which  will  employ  increasing  numbers  of  spe¬ 
cialized  reasoners.  As  the  number  of  reasoners  within  a 
single  system  increases,  it  will  become  increasingly  impor¬ 
tant  that  some  organizing  principle  if  available  to  in¬ 
tegrate  these  various  reasoners.  Our  decision  to  organize 
all  universal  and  default  knowledge  within  the  context  of 
particular  concepts  illustrates  a  belief  that  the  "concept- 
oriented"  (a.k.a.  "frame-oriented")  approach  will  prove 
to  be  a  successful  organizing  principle  for  wider  and 
wider  classes  of  knowledge.  Such  an  approach  may  be 
contrasted  with  that  of  the  current  generation  of  rule- 
based  systems  (including  hybrid  frame-  and  rule-based 
systems):  in  those  systems,  knowledge  which  we  have 
■Lts-ed  ;l-  univer-al  or  dcfa  ilt  knowledge  (other  than 


"default  values")  tends  to  be  dumped  unceremoniously 
into  a  "rule  base”,  i.e.,  such  systems  provide  no  formal 
scheme  for  structuring  that  knowledge. 

3.  Baaic  Terminology 


Here  we  take  time-out  to  formalize  some  of  our 


terms. 


By  a  concept  we  mean  an  "intentional  description" 
of  something.  The  most  general  instance  of  a  concept  Is 
called  "Thing".  A  relation  'is  a  concept  which  defines  a 
set  of  k-tuples,  with  k  being  fixed  for  each  individual 
relation.  By  convention,  the  the  term  "concept"  is  often 
used  to  refer  to  (the  more  specialized  notion  of)  a  unary 
relation.  Thus,  the  detconcept  form  defines  a  unary 


relation. 


A  binary-relation  tor  which  the  roles  domain  and 
range  have  been  assigned  will  be  called  a  mapping.  By 
convention,  the  term  "relation"  may  be  used  in  place  of 
the  word  "mapping",  and  the  form  d«f relation  is  used 
to  deHne  a  mapping.  The  most  general  instance  of  a 
mapping  is  called  "aaps-to”.*  The  Loom  implemen¬ 


tation  is  intended  to  accommodate  relations  of  order 


greater  than  two,  but  a  complete  syntax  for  defining 
higher-order  relations  has  not  yet  been  worked  out.  A 
relation  which  has  been  reified  (equated  with  a  unary 
concept  of  the  same  name)  is  termed  a  relationship. 


The  domain  of  a  mapping  is  not  considered  to  be  a 
part  of  its  (TBox)  definition.  The  association  of  a  map¬ 
ping  with  a  particular  (domain)  concept,  other  than  the 
concept  THING,  induces  a  sub-relation  we  call  a  role}  A 
role  restriction  which  associates  a  mapping  M  with  a 
concept  C  defines  a  role  such  that  R^w  is  a  subset 
of  M,  and  has  domain  C.  A  value  restriction  is  a  role 


^'inapt-to*  corresponds  to  the  NIKL  relation  ‘MoeiGeneraJRole* 
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lures  in  the  system  mhich  esn  be  identifie  i 


i  e  there  irt  no  struc- 
u  roles 


iV*C 


few 


*Tr\OT* 


restriction  which  restricts  the  range  of  R^, M,  while  a 
number  restriction  is  a  role  restriction  which  places 
bounds  on  the  number  of  role  fillers  of  Rcw  that  can  be 
associated  with  a  single  instance  of  C.  A  composition  of 
mappings  Mj,  ....  Mk  such  that  the  domain  of  is 
restricted  to  a  particular  concept  (other  than  THING)  is 
called  a  role  chain. 

Loom  distinguishes  between  "primitive"  and 
"defined"  concepts  (and  relations).  A  concepts  is 
primitive  if  no  complete  definition  can  be  given  for  it 
(see  [Vilain  84,  p.  549  or  ,  Brachman  and  Schmolze  85]); 
otherwise  it  is  defined.  Concepts  and  relations  are  or¬ 
ganized  into  a  taxonomy  based  on  a  partial-ordering  rela¬ 
tion  called  "specializes".  A  concept  Cj  specializes  a  con¬ 
cept  C„  if  and  only  if  membership  in  Cj  entails  member¬ 
ship  in  C.,,  i.e.  iff 

h  Vx[C,(x)  -  C,(x)]. 

An  instance  of  a  specializes  relation  between  two  concepts 
may  be  declared  explicitly  in  a  concept  definition,  or  it 
may  be  deduced  by  the  classifier. 

A  value  is  an  object  which  corresponds  to  a  logical 
constant  in  a  knowledge  base,  and  is  typically  left  un¬ 
defined  in  a  knowledge  base.  The  numbers  1,  3,  and  8.2, 
and  the  sexes  Male  and  Female  are  examples  of  values. 
A  concept  which  is  defined  by  enumerating  its  instances 
is  called  a  set.  Currently,  all  of  the  sets  we  define  in  the 
TBox  are  sets  of  values.  Number  and  Sex  are  examples 
of  sets.  A  (denumerable)  set  for  which  precedessor  and 
successor  relations  exist  is  termed  an  interval,  e.g.,  In¬ 
teger  and  Days-of-the-Week  are  intervals. 

To  classify  a  concept  means  to  link  it  into  the 
specialization  latike  so  that  (il  it  is  below  all  concepts 
which  it  specializes,  and  (ii)  it  is  above  all  concepts  which 
specialize  it.  The  most  specific  generalization  (MSG)  of 
a  concept  is  the  set  of  those  concepts  which  are/would 
become  it  -  direct  ancestors  (parents)  if  it  were  classified. 


To  recognize  an  ARox  object/instance  x  means  to 
compute  the  set  of  concepts  {C^}  such  that  for  each  Cj,  x 
is  an  instance  of  Cj,  and  x  is  not  an  instance  of  any  des¬ 
cendant  of  Cj.  The  set  { Cj }  is  referred  to  as  the  MSG  of 
x.  In  an  informal  discussion  we  may  use  the  term 
"classification"  to  refer  to  either  the  classification  or  the 
recognition  process. 

4.  The  TBox 

In  this  section  we  present  the  syntax  and  semantics 
of  TBox  definitions  for  (unary)  concepts,  (mapping)  rela¬ 
tions,  sets  and  intervals.  Occasionally  within  this  discus¬ 
sion  we  will  pause  to  point  out  some  of  the  deductions 
which  the  Loom  classifier  will  (or  will  not)  be  able  to 
make.  These  comments  are  intended  to  foster  an  ap¬ 
preciation  for  what  kinds  of  inference  one  can  expect 
from  a  classifier.  Next  comes  a  brief  discussion  outlining 
our  reasons  for  prohibiting  cyclically-defined  concepts, 
and  we  conclude  with  a  presentation  of  three  additional 
restrictions  which  Loom  imposes  on  TBox  definitions. 

4.1.  Defconcept  and  Defrelation 

A  formal  semantics  for  the  term-forming  operations 
defconcept  and  defrelation  appears  as  Appendix  B.  The 
simple  definitional  constructs  listed  in  the  figure  can  be 
combined  within  a  concept  or  relation  definition  to  form 
compound  definitions.  The  semantics  for  such  a  com¬ 
pound  definition  are  defined  as  the  logical  conjunction  of 
the  individual  lambda  definitions. 

For  example,  referring  to  the  Engines  and  Cars  KB 
in  Figure  A-l,  suppose  we  declare  a  new  concept 

(defconcept  (  specializes  Engine) 

(  restriction  cylinders  (  »ln  4)  (  sax  6)) 
(restriction  fuel  (  vr  Gasoline))) 

This  concept  means  "an  engine  fueled  by  gasoline  which 

has  between  4  and  6  cylinders."  The  TBox  classifier  will 

discover  that  this  concept  specializes  the  concept  labeled 

Internal -Coabust ion -Engine. 


I.t  <.*  >.< 


The  Familial  Relations  KB  in  Figure  A-4  illustrates 
how  dafralation  constraints  can  be  combined  to  form 
terms  for  the  relations  parant,  father,  grandfather,  etc. 
The  classifier  will  determine,  among  other  things,  that 
grandfather  specializes  grandparent  and  that  parent  and 
grandparent  specialize  ancestors.  A  few  short-hand  nota¬ 
tions  are  provided  in  addition  to  the  operators  illustrated 
in  Figure  A-4.  The  following  pairs  of  forms  are  equiv- 


The  forms 

(  restriction  H  (  number  k))  and 

(  restriction  M  (  am  k)  (  aa x  k)), 

the  forms 

(  restriction  (  vrdlff  M  C)  )  and 

(  restriction 

(defrelatlon  (  specializes  M)  (  range  C))  .  .  .). 

the  forms 

(  restriction  (  closure-of  M)  .  .)  and 

(  restriction  (defrelatlon  (closure-of  M) )  . ..). 


Loom's  constraint  clause  extends  the  CNIKL  con¬ 
struct  referred  to  as  a  "role-constraint"  or  "role-value- 
map"  by  (1)  allowing  for  other  operators  than  just  set- 
equality  and  set-containment,  and  (2)  allowing  a  value  to 
take  the  place  of  a  role-chain.  The  argument  "CP"  in 
the  clause 

(  constraint  CP  (  )  (  )) 

must  name  a  relation  which  falls  in  the  sublattice  rooted 
at  the  relation  Cosputs-Rslation.  Figure  A-2  illustrates 
some  compute  relations.  The  operator  for  computing 
set-equality,  set-inequality,  and  set-cont...nraent  are  other 
examples  of  compute  relations. 

Again  referring  to  the  Lngines  IvB,  let  us  declare 
two  new  conce;  ts: 

(dsfconcspt  Blg-Engln# 

(  constraint  grsatsr-than  (horse-pover)  120)) 
(def concept  V«ry-Blg-Engln« 

(  constraint  grsatsr-than  (borss-povsr)  200)) 

We  plan  )  u;  era  le  the  Loom  classifier  so  that  it  will  be 
able  to  ■!•  :  ice  that  Vsry-Big-Engins  specializes 
iilg  Er.glr.e.  The  analytic  will  necessitate  recognizing  the 


truth  of  (grsatsr-than  200  120)  ,  and  will  involve 
reasoning  about  the  transitivity  of  the  grsatsr-than  rela¬ 
tion.  During  a  1986  NIKL  users  workshop  (Moore  86], 
Ron  Brachman  discussed  the  possibility  of  extending  a 
NIKL-like  system  to  include  a  couple  of  new  "boxes"  in 
addition  to  the  traditional  TBox  and  ABox.  One  of  those 
boxes  he  termed  a  "Mathematics  Box",  which  would  be  a 
specialized  reasoner  with  the  ability  to  derive  mathemati¬ 
cal  inferences  in  conjunction  with  the  TBox  reasoner. 
The  numerical  reasoning  facility  just  hinted  at  represents 
an  embryonic  step  in  the  direction  of  developing  a  full- 
fledged  mathematics  box. 

We  will  conclude  this  section  will  an  example  con¬ 
taining  definitions  for  which  Loom  cannot  deduce  the  im¬ 
plied  subsumption  relations.  Referring  to  the  Familial 
Relations  KB  again,  consider  the  following  definitions  of 
a  concept  named  "Only-Child": 

(dafconcept  0nly-Cbild-l 

(. constraint  aquals  ««lf  (parant  child))) 
(dafconcapt  Only-Chlld-2 

( : raatrlctlon  sibling*  (sax  0))) 

The  current  Loom  classifier  cannot  deduce  that  the  con¬ 
cepts  0nly-Chlld-i  and  Only-Chlld-2  are  equivalent. 
The  NIKL  classifier  is  similarly  unable  to  deduce  this 
equivalence  relation  (when  applied  to  CNIKL  analogues 
of  the  above  definitions).  Our  current  development 
philosophy  is  that  we  are  committed  to  developing  a  sys¬ 
tem  which  makes  inferences  which  are  sound,  but  not 
necessarily  complete.  One  of  the  philosophical  goals  of 
the  Loom  system  is  to  investigate  empirically  where  the 
boundaries  should  be  on  the  expressive  power  of  a  TBox. 
Once  those  bounds  have  been  more-or-less  established,  it 
may  be  appropriate  to  revive  the  goal  of  developing  a 
reasoner  which  is  as  complete  as  we  can  make  it. 

4.2.  Defset  and  Definterval 

This  section  describes  the  operators  d*f*«t  and 
dcfiotarval,  which  can  be  employed  to  define  sets  and 
intervals,  and  also  to  define  concepts  corresponding  to 
the  values  enumerated  in  those  sets  'intervals.  Our  ex- 
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amples  will  reference  the  Sets  and  Intervals  KB  in  Figure 

A-3. 

In  many  cases,  there  is  a  tight  coupling  between 
values  in  a  set  or  interval  which  represent  "qualities" 
(e.g.,  the  sex  Male  or  the  color  Red)  and  concepts  such  as 
Maie-Aniaal  or  Red-TMng  which  are  defined  by  having 
one  of  their  attributes  restricted  to  the  corresponding 
value:  Definitions  for  Male-Anlaal  and  Rad-Tblng  might 
be 

(defcoocept  Male-Anlaal  (: specializes  Anlaal) 
(restriction  sex  (vr  Male))) 

(defconcept  Red-Thlng 

(: specializes  Monochroae-Thlng) 

(: restriction  color  (  vr  Red))). 

Thus,  we  have 

Vx[(Animal(x)  A  sex(x,  Male))  — >  Male-Animal(x)]. 
'ix[(\tonochrome—Thing(x)  A  color^x,  Male)) 

»—  Red—  Thing(x)). 

The  Loom  syntax  for  sets  and  intervals  includes  an  op¬ 
tional  "partitions"  clause  which  produces  the  set  of 
definitions  needed  to  characterize  this  behavior. 

The  declaration 

(defset  Sex  (values  Male  Feaale)) 
defines  a  set  Sex  and  the  values  Male  and  Feaale.  To  in¬ 
troduce  the  concepts  Male-Anlaal  and  Feaale-Anisal,  we 
can  augment  our  definition  with  the  clause 
(partitions  Anlaal)  (Figure  A-3  illustrates  the  com¬ 
plete  definition).  This  larger  declaration  implicitly 
declares  the  following  expressions: 

(defrelatlon  Sex  prlaltlve 

(  axioms  (  doaaln  Anlaal)  (  range  Sex))) 
(defconcept  Male-Anlaal  (specializes  Anlaal) 

(  restriction  Sex  Male)) 

(defconcept  Feaale-Anlaal  (  specializes  Anlaal) 

(  restriction  Sex  Feaale)) 

In  addition,  the  declaration  for  the  concept  Anlaal  is  aug¬ 
mented  by  a  clause  which  indicates  that  Male-Anlaal  and 
Feaale-Anlaal  form  a  disjoint  covering  of  Animal. 

We  next  turn  our  attention  to  the  interval 
Naval -Rar.x  defined  in  Figure  A-3.  The  declaration  of 
Naval -Rank  implies  the  definition  of  a  relation 
Naval -Rar.k.  and  a!-,  implies  the  declaration  of  the  con¬ 


cepts  Saaaan-Recrult,  Seaaan-Apprentlce,  ...  ,  Adalral. 
8  The  implied  declaration  for  Adalral  is 

(defconcept  Adalral  (: specializes  Naval-Person) 

( irestrlctlon  Naval-Rank  Adalral))  7 

Because  Naval-Rank  is  specified  as  an  interval, 
rather  that  as  a  set,  the  relations  "successor"  and 
"predecessor"  are  defined  for  its  instances.  Their  defini¬ 
tion  corresponds  to  the  order  of  values  in  the  "values" 
clause.  For  example,  (successor  Coaoander  Captain)  is 
true.  The  successor  and  predecessor  relations  may  ap¬ 
pear  within  the  role  chains  of  a  constraint  clause.  A 
square-bracket  notation  can  be  employed  to  define  a 
(contiguous)  subset  of  an  interval.  This  is  illustrated  in 
the  definition  of  the  set  Naval-Of f lcer-Rank.  and  in  the 
definitions  below  that  for  Natural-Nuaber, 
Posltlvs-Integer,  and  Non-Negative-Integer.  The 
semantics  of  subsumption  for  intervals  is  the  same  as 
that  for  sets.  For  example,  the  interval  defined  by 

(def interval  (specializes  Integer) 

(values  375)) 

specializes  the  interval  defined  as 

(deflnterval  (specializes  Integer) 

(: values  [2. .»]) ) 

4.3.  How  to  Avoid  Cycles 

A  concept  (or  relation)  definition  depends  on 
another  definition  if  it  references  the  other  concept  by 
name  within  its  definition.  If  these  depends-on  links 
form  a  cycle,  then  we  say  that  the  definitions  involved 
are  cyclic.  The  designers  of  the  NIKI,  system  expressly 
permitted  cyclic  definitions.  However,  the  semantics  as¬ 
sociated  with  cyclic  CNJKL  definitions  was  never  fully 
worked  out.  and  the  behavior  of  the  NIKI,  classifier  when 
it  encountered  cycles  was  f;ir  from  satisfactory.  Loom 
has  taken  an  opposite  position  --  cyclic  definitions  are  il¬ 
legal  in  l/oom. 

c 

In  the  declaration  of  ■Naval-Hank*,  the  clause  "(suffix  Nil)" 
prevented  the  suffix  •-Naval-Person *  from  hem*  appended  to  each 
new  concept 

'Observe  that  the  concepts  •adimr.il  *>  ptm.i;"  and  "admiral  a.' 
navaJ-rank"  have  the  same  name  Loom  will  aut<>maiicall>  add  suf¬ 
fixes  "-1*  and  *-2"  to  distinguish  l>rt»ern  them 


A  primary  motivation  for  allowing  cycles  was  to 
avoid  placing  a  restriction  on  what  concepts  could  appear 
within  a  value  restriction  clause.  Consider  the  following 
definition  of  Human: 

(def concept  Huaan  : primitive  (: specialize*  Maaaal) 

( : restriction  parent*  ( : vr  Huaan) ) ) 

The  value  restriction  (:vr  Huaan)  allows  the  system  to 

infer  "If  an  individual  is  Human,  then  so  are  its  parents, 

and  their  parents,  and  so  on."  Because  that  value 

restriction  is  self- referential  (defining  a  cycle  of  length 

one),  it  is  not  permitted  in  Loom.  However,  Loom  does 

allow  an  equivalent  restriction  to  be  expressed  as  an 

axiom  in  the  UBox: 

(d*f concept  Huaan  .prlaltlve  (: specializes  Maaaal) 

( : axloas 

(: restriction  parents  ( : vr  Huaan)))) 

Thus,  we  retain  in  Loom  the  ability  to  make  statements 
such  as,  "the  parents  of  humans  are  also  human";  we 
just  don’t  allow  them  to  be  included  as  a  part  of  the 
(terminological)  definition  of  a  concept. 

5.  The  UBox 

The  knowledge  which  we  place  in  the  Universal  box 
augments  individual  TBox  definitions  with  what  we  call 
universal  or  contingent  knowledge.  The  expressive  power 
of  the  Loom  language  increases  significantly  when  the 
definitional  language  is  extended  to  include  expressions  of 
universal  knowledge.  This  combined  language  admits  a 
correspondingly  larger  class  of  inferences. 

This  section  will  first  define  the  different  types  of 
knowledge  which  we  class  as  "universal".  Next,  we  in¬ 
troduce  the  notion  of  a  "stable"  classifier,  which  serves 
to  sharpen  the  definitional  boundary  between  ter¬ 
minological  and  universal  knowledge.  Finally,  we  will 
present  the  representational  model  and  classification  algo¬ 
rithm  adopted  by  the  Loom  architecture  to  handle 
universal  knowledge. 

5.1.  Types  of  Universal  Knowledge 

In  anticipation  of  our  later  discussion  on  how  Loom 
represents  universal  knowledge,  we  will  group  our  univer¬ 


sal  knowledge  into  four  categories.  Referring  to  universal 
knowledge  that  is  attached  to  a  concept  "P",  the 
categories  are: 

1.  Contingent  restrictions  and  constraints  — 
these  are  restrictions  or  constraints  which 
necessarily  apply  to  an  instance  "x"  if  P(x) 
holds.  These  are  often  called  "necessary 
conditions"; 

2.  Implications  --  these  are  statements  of  the 
form  "P  implies  Q"  (where  Q  is  a  concept 
which  does  not  subsume  P).  Often  called 
"sufficient  conditions"; 

3.  Equivalences  —  these  are  statements  of  the 
form  "P  if  and  only  if  Q".  Often  called 
"necessary  and  sufficient  conditions"; 

4.  Other  non-definitional  knowledge  about  con¬ 
cepts  and  relations.  Currently  this  knowledge 
consists  of  covering  relations,  disjointness  rela¬ 
tions,  marking  concepts  as  "individual",  and 
domain  and  range  constraints  on  mappings. 

5.1.1.  Contingent  Restrictions  and  Constraints 

The  "axioms"  clause  of  a  concept  or  relation  defini¬ 
tion  states  universal  knowledge  which  applies  to  that  con¬ 
cept  or  relation.  The  Engines  and  Cars  KB  of  Figure  A-l 
illustrates  several  such  clauses.  The  next  few  examples 
will  be  drawn  from  that  KB. 

The  clause 

(: axloas  (:res  (ivrdlff  has-coaponent  Engine) 
(:nuaber  1))) 

which  appears  in  the  definition  of  Car  is  an  example  of  a 
"contingent  restriction".  The  meaning  of  the  clause  is 

Vx\Car(x)  — *  3  exactly  one  y 

( has—component(x ,  y)  A  Enyine(y))). 

This  is  sometimes  referred  to  as  a  "necessary  condition" 
because  it  translates  as  "it  is  necessarily  the  case  that  a 
car  has  exactly  one  engine."  In  general,  the  meaning  of  a 
restriction  (or  constraint)  appearing  within  an  "axioms" 
clause  of  a  def  concept  form  defining  a  concept  C  is,  "this 
restriction  (constraint)  applies  to  all  objects  which  are  in¬ 
stances  of  C". 


5.1.2.  Implications  and  Equivalence  Relations 

The  clause  (: axioms  (:lsplles  Car))  which  ap¬ 
pears  within  the  defconcept  form  which  defines 
Battery-powered-Vehicle  is  an  example  of  an 
implication.  Its  meaning  is 
Vx[Ba£terj/— Powered— Ve/»te/e(x)  ->  Car(x)]. 

This  form  of  knowledge  is  sometimes  called  a  "sufficient 
condition"  because  it  can  be  translated  as  "to  determine 
is  x  is  an  Car,  it  is  sufficient  to  determine  that  x  is  a 
Battery-Powered- Vehicle." 

It  is  important  to  distinguish  the  difference  in 
semantics  between  an  implication  (an  "implies"  relation) 
and  a  "specializes"  relation.  While  the  logical  form  as¬ 
sociated  with  each  of  them  is  identical,  the  semantics  of 
the  specializes  relation  is  significantly  stronger.  The 
statement  "B  specializes  A"  says  not  only  that  (1)  B 
implies  A,  but  also  that  (2)  B's  (TBox)  definition  in¬ 
cludes  the  definition  of  A,  and  (3)  B  inherits  the  (UBox) 
properties  of  A. 

A  two-way  implication  established  between  a  pair 
of  concepts  defines  an  equivalence  relation.  More 
generally,  any  cycle  of  implications  through  a  set  of  con¬ 
cepts  establishes  an  equivalence  relation  between  each 
pair  of  concepts  in  that  set.  Suppose  a  set  of  concepts 
{CJ  have  been  defined  such  that  they  are  pairwise- 
equivalent.  While  the  TBox  sees  the  Cj  as  distinct  con¬ 
cepts,  the  UBox  view  of  this  knowledge  sees  a  single  con¬ 
cept  C^-  which  combines  all  of  the  knowledge  declared  in 
each  of  the  C(  (this  is  described  in  more  detail  in  section 
5.3.).  This  means  that  universal  knowledge  (other  than 
the  "implies"  relations)  can  be  distributed  in  any  number 
of  ways  among  the  C^s,  and  the  semantics  will  always  be 
the  same. 

The  preferred  way  to  model  a  set  of  equivalent  con¬ 
cepts  (C()  is  to  explicitly  declare  an  additional  concept  C 
w  hich  specializes  each  of  the  Cjt  and  which  contains  all  of 
the  universal  knowledge  associated  with  the  Cj,  except 
for  a  clause  (  axioas  (implies  C))  which  appears  in 


each  of  the  Cj  definitions.  Our  definition  of  the  concepts 
Dleaal-Oll-Engln*,  Thlng-Wltti-Glow-Plugs, 
V»ry-Hlgh-Co«pr*gslon-Englne,  and  Diesel-Engine  in 
Figure  A-l  illustrates  this  type  of  modeling. 

5.1.3.  Coverings  and  Disjointness  Classes 

A  covering  for  a  concept  "A"  is  a  set  of  concepts 
whose  union  contains  A.  Loom  syntax  requires  that  the 
concepts  within  such  a  covering  specialize  A,  so  that  the 
union  of  the  covering  concepts  equals  A.  The  meaning  of 
the  clause  (: axioms  (:  covering  b  C))  within  a 
defconcept  for  A  is 
Vx[A(x)  -  (B(x)vC(x))]. 

Declarations  of  unary  coverings  (coverings  containing  a 
single  concept)  are  illegal  in  Loom  because  they  are  logi¬ 
cally  equivalent  to  "implies"  relations,  and  hence  are 
redundant. 

A  disjointness  class  is  a  set  of  concepts  which  are 
declared  to  be  mutually  disjoint.  A  disjointness  class  is 
always  defined  with  respect  to  a  concept  which  subsumes 
the  members  of  the  class.  The  meaning  of  the  clause 

(:axlOB8  (:dlBjolnt  B  C)) 
within  a  defconcept  for  A  is 
Vx[B(x)  -  -C(x)). 

A  disjoint-covcnng  of  a  concept  A  enumerates  a  set 
of  concepts  which  partition  A,  i.e.,  it  is  interpreted  as  the 
logical  conjunction  of  a  covering  declaration  and  a  dis¬ 
jointness  declaration. 

The  Numeric-Comparison  KB  in  Figure  A-2  il¬ 
lustrates  some  declarations  of  coverings  and  disjoint- 
coverings.  The  covering  defined  for  the  relation 
numeric-comparison  declares  that  the  relations 
greater-or-equal  and  less-or-equal  cover 
numeric-comparison.  The  disjoint-covering  declaration 
for  greater-or-equal  states  both  that  greater-or-equal 
is  covered  by  greater- than  and  equal,  and  that  the  rela¬ 
tions  greater-than  and  equal  are  disjoint.  Loom 


about  &  relation.  The  declaration 


provides  functions  for  asking  questions  about  (declared  or 
derived)  disjointness  and  covering  relations,  such  as  "Are 
concepts  A  and  B  disjoint?",  "Do  concepts  A,  B,  and  C 
cover  concept  D’”.  or  "List  all  coverings  for  concept  D". 

Loom  requires  that  the  concepts  or  relations  ap¬ 
pearing  in  a  covering,  disjointness  class,  or  disjoint- 
covering  must  all  be  primitive.  The  philosophical  jus¬ 
tification  for  this  restriction  is  that  if  one  or  more  of  the 
members  of  the  covering  and/or  disjointness  class  are  not 
primitive  t licit  either  (i)  the  covering  and/or  disjointness 
relations  could  have  been  logically  inferred  on  the  basis 
of  other  knowledge  or  (ii)  such  relation(s)  could  be 
derived.  In  the  former  case,  the  covering 
and/disjointness  declaration  is  redundant,  and  should  be 
dropped.  In  the  latter  case,  there  must  have  been  some¬ 
thing  left  unstated  about  the  non-primitive  concepts, 
w  hich  suggests  that  they  are  in  fact  primitive. 

The  implementors  of  the  NIKL  system  encountered 
a  practical  reason  for  requiring  members  of  a  disjointness 
class  to  he  primitive.  That  restriction  prevented  an 
anomaly  which  arose  in  a  situation  in  which  so-called 
“incoherent"  concepts  were  being  classified.  The  pos¬ 
sibility  of  a  similar  anomaly  arising  in  conjunction  with 
covering  declarations  has  not  yet  been  explored. 

We  are  considering  omitting  the  disjoint  clause  al¬ 
together  from  the  Loom  language,  owing  to  the  obser¬ 
vation  that  we  have  not  yet  encountered  the  use  of  a  dis¬ 
jointness  declaration  in  a  context  where  an  obvious  cover¬ 
ing  relation  did  not  also  exist,  i.e.,  where 
disjomt-coverlng  could  not  have  been  substituted.'  Our 
syntactic  requirement  that  a  disjointness  class  be  defined 
relative  !.<  a  particular  concept  anticipates  this  future 
restriction. 

5.1.4.  Domain  and  Range  Restrictions 

“I  i  "  and  "ranee"  clauses  w  hich  appear 

w/. bin  "  ixioiiis"  clause  state  mcessarv  conditions 


(Correlation  M  . . . 

(axloaa  (domain  A)  ( : rang*  B))) 

makes  the  universal  statement 

Vzy[M(x,  y)  —  A(x)  A  B(y)]. 

Knowledge  about  domain  and  range  constraints  is 
referenced  during  the  "model-building"  phase,  when  the 
initial  definitions  of  concepts  and  relations  are  being 
refined  and  checked  for  coherence.  In  this  context,  these 
constraints  function  as  "integrity  constraints". 

5.1.5.  Individual  Concepts 

Marking  a  concept  as  "individual"  means  that  its 
extension  has  cardinality  at  most  one.  We  have  iden¬ 
tified  some  inferences  that  can  be  made  on  the  basis  of 
individual  markings  on  concepts,  but  none  of  these  in¬ 
ferences  are  particularly  useful.  Thus,  this  feature  cur¬ 
rently  serves  only  as  a  place-holder,  awaiting  a  user  who 
will  conceive  of  a  use  for  it. 

The  presence  of  the  “individual"  marking  is  a  pan 
of  Loom’s  NIK L  heritage.  Because  most  applications  of 
NIKL  operated  without  an  ABox  —  individual  concepts 
served  in  lieu  of  real  ABox  instances. 

5.2.  Stable  and  Non-Stable  Classifiers 

Consider  the  following  scenario:  A  rather  shady- 
looking  character  produces  from  his  capacious  overcoat  a 
large  black  box,  which  he  claims  is  a  seventh-generation 
classifier  of  terminological  knowledge,  guaranteed  to 
produce  sound  (although  not  necessarily  complete)  in¬ 
ferences  very  quickly.  We  decide  to  test  out  his  BBC 
(black-box  classifier).  First  we  store  into  the  BBC  the 
definitions  of  two  concepts  which  we  call  A  and  B.  We 
than  ask  the  BBC  "Does  B  specialize  A*",  and  it 
responds  (very  quickly)  "No".  Next,  we  enter  a  few 
more  definitions  into  the  BBC.  and  again  ask  the  BBC 
"Does  B  specialize  A’"  This  time,  its  rapid  rejoinder  is 
"Yes"!  Should  we  buy  his  BBC  i his  price  is  very 
reasonable)’ 
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The  answer  is  no:  Let  us  define  a  stable  classifier 
(or  recognizer)  to  be  one  which  produces  the  same 
answers  to  subsumption  questions  independently  of  ad¬ 
ditions  or  subtractions  to/from  the  knowledge  base  (here 
we  assume  that  no  concept  definitions  are  modified,  and 
that  at  no  time  does  the  knowledge  base  contain  un¬ 
defined  references).  "Stability"  is  a  highly-desirable  fea¬ 
ture  in  a  TBox,  because  it  provides  a  certain  guarantee 
that  when  TBox  knowledge  is  shared  across  several 
knowledge  bases  (e.g.,  by  several  applications)  it  will 
retain  the  same  "meaning"  in  each  of  those  contexts. 
We  propose  that  "stability"  be  considered  a  test  which 
serves  to  exclude  some  reaso tiers  from  being  considered 
TBox  classifiers.  ("Soundness"  should  be  another  TBox 
requirement).  The  Loom  Tbox  of  an  example  of  a  stable 
classifier;  our  friend’s  BBC  is  not  stable. 

The  Loom  UBox  classifier/recognizer  is  not  stable! 
Consider  the  Cars  KB  in  Figure  A-l.  Suppose  we  make 
the  following  assertions 

(assert  (Motor-Vehicle  BPV)  (2-Person-Vehlcle  BPV) 
(Battery-Powered-Engine  E) 

(has-conponent  BPV  E)) 

Now  we  ask,  "Is  BPV  an  instance  of  2-Person-Car?"  The 
UBox  recognizer  will  make  the  following  inferences 

(Battery-Powered-Vehicle  BPV) 

(Car  BPV)  because  of  the  "implies"  axiom 

(2-Person-Car  BPV) 

and  conclude  "Yes".  However,  if  we  remove  the  defini¬ 
tion  for  Battery-powered-Vehicle  (or  if  it  never  existed) 
and  re-run  the  UBox  recognizer,  it  will  not  conclude  ei¬ 
ther  (Car  BPV)  or  (2-Person-Vehlcle  BPV)  .8  On  the 
other  hand,  if  we  run  the  Loom  TBox  recognizer  on  the 
same  knowledge  base  and  assertions,  it  will  fail  in  both 
cases  to  recognize  that  BPV  is  a  car  (or  a  2-person  car). 
This  behavior  occurs  because  the  axiom 
"Battery-powered-Vehicle  implies  Car"  is  invisible  to  the 

8Note:  This  does  not  mean  that  it  conclude*  "--(Car  BPV)".  It 
merely  fails  to  infer  "(Car  BPV)*  —  the  (  Box  classifier  is  not  a  non¬ 
monotonic  reaaoner. 


TBox.  The  stability  of  the  TBox  classifier  derives  from 
the  restrictions  we  place  on  what  kinds  of  knowledge  are 
classed  as  terminological  in  the  TBox,  not  from  the  par¬ 
ticular  inference  algorithm  chosen  --  we  deliberately  ex¬ 
clude  from  the  TBox  classes  of  knowledge  which  intro¬ 
duce  non-stable  behavior. 

5.3.  Modeling  and  Classification  of  Universal 
Knowlt  .ge 

This  section  represents  a  long  engineering  note.  We 
first  describe  the  internal  model  adopted  by  Loom  to 
represent  universal  knowledge,  and  then  give  some  in¬ 
sight  into  the  workings  of  Loom’s  UBox  classification  al¬ 
gorithm. 

In  a  Loom  concept  network,  separate  objects,  which 
we  shall  refer  to  as  CT  and  Cy,  are  defined  to  represent 
the  TBox  and  UBox  knowledge  associated  with  a  single 
concept  C.9  CT  contains  exactly  the  definitional 
(terminological)  component  of  C.  Cy  contains  both  the 
definitional  and  contingent  knowledge  knowledge  as¬ 
sociated  with  C.  Thus,  by  construction,  Cy  always  spe¬ 
cializes  Cj.  An  implies  link  links  CT  to  Cy,  and  has  the 
meaning  VzjC^x)  -♦  CJ^x) J.  In  other  words,  CT  implies 
Cy. 

Within  a  UBox  concept,  contingent  restrictions  and 
constraints  are  merged  into  a  single  definition,  and  are 
classified  according  to  that  definition.  Suppose,  for  ex¬ 
ample,  that  we  made  the  following  declarations: 

(defconcept  C  (: restriction  R  (:aln  1)) 

(axloas  (: restriction  S  (:aln  1)))) 

(defconcept  D  ( : restriction  R  (:»ln  i)) 
(restriction  S  (:aln  1))) 
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Browsers  of  Loom  knowledge  bases  should  be  aware  of  the  follow¬ 
ing:  Loom  maintains  separate  name  spaces  for  TBox  objects  and 
UBox  objects.  In  the  TBox  name  space,  only  TBox  objects  are 
visible,  and  C ^  has  the  name  "C*.  In  the  UBox,  only  UBox  objects 
are  visible,  and  Cy  has  the  name  "CV 


The  classifier  cannot  distinguish  between  the  objects  CU 
and  D.J-,  and  hence  will  merge  these  two  concepts. 

Implications  are  modeled  as  follows:  Suppose  we 
lecture 

(defconcept  A 

(  axloas  (  laplles  B))) 

Rather  than  placing,  say,  an  "implies"  link  between  Ay 
and  By.  Loom  captures  the  semantics  of  the  implication 
axiom  by  merging  all  of  the  knowledge  in  By  into  Av  (in 
effect,  "compiling  out"  the  "implies"  link).  Equivalence 
relations  add  nothing  new  to  the  model,  since  they  just 
consist  of  cycles  of  implication  relations.  If  we  declared 
that  "A  implies  B",  and  also  that  "B  implies  A",  Loom 
would  merge  By  into  A...  and  would  also  merge  Ay  into 
B.-.  making  Ay  and  By  identical.  The  classifier  would 
then  ::.*-rge  these  into  a  single  I’Box  concept. 

Loom's  internal  model  of  three  of  our  original  four 
categories  of  universal  knowledge  can  thus  be  ac¬ 
complished  with  the  addition  of  only  one  new  link,  the 
"implies"  link.10  An  important  property  of  the  model  is 
that,  in  a!i  cases,  the  "implies"  links  connect  more 
general  concepts  to  more  specific  ones:  The  Loom  (and 
NIKL)  TBox  classifiers  operate  by  picking  an  initial  set 
of  "starting  points"  (concepts)  and  then  traversing  down 
"subC"  links  which  connect  each  concept  to  those  con¬ 
cepts  which  directly  specialize  it.  Loom's  UBox  classifier 
traverses  down  both  "subC"  and  “implies"  links.  Be¬ 
cause  the  "subC"  and  "implies"  links  form  an  acyclic 
directed  gra[  h.  termination  of  the  l" 'ox  classifier  is 
guaranteed. 

During  the  process  of  classifying/recognizing  an  ob¬ 
ject  X  in  the  VBox.  the  traversal  of  an  "implies*  link  can 
cause  knowledge  to  be  acquired  about  X  which  is  not  en¬ 
tailed  by  its  definition.  This  is  the  source  of  the  "non¬ 
liability"  in  the  UBox  classifier.  Recall  the  example  in 
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section  5.2  which  traced  the  recognition  of  the  object 
"BPV".  One  of  the  algorithm’s  starting  points  is  the 
concept  2-Paraoa-VahlcI*.  If  we  visit  its  child 
2-p«rson-Car  and  make  the  test  (2-Person-Car  X)  before 
having  traversed  the  "implies"  link  between 
Battary-Po*«r«d-V*hlcl*T 

Battary-Powarad-Vahlclay,  we  would  receive  a  negative 
answer.  Traversing  that  link  causes  us  to  acquire  the 
knowledge  (Car  BPV).  After  this  point,  the  test 
(2-Paraon-Car  X)  returns  in  the  affirmative.  Hence,  the 
first  test  to  see  if  X  was  a  2-person  car  represented 
wasted  effort. 

One  practical  consequence  of  non-stability  is  that 
the  ordering  of  subsumption  tests  is  more  critical  for 
UBox  classification  than  for  TBox  classification.  Further¬ 
more,  it  is  not  always  the  case  that  careful  ordering  of 
subsumption  tests  can  avoid  the  necessity  to  repeat  some 
subsumption  tests  (unless  you  have  an  "oracle"  at  your 
disposal).  Theoretically,  UBox  classification  could  be  sig¬ 
nificantly  slower  than  TBox  classification.  We  have  not 
yet  performed  empirical  tests  which  compare  the  relative 
performance  of  the  two  algorithms,  but  we  expect  that 
we  will  be  able  to  achieve  reasonable  performance  from 
the  UBox. 

0.  Default  Knowledge 

Loom  establishes  a  separate  "box"  for  representing 
"default  knowledge"  --  knowledge  representing  state¬ 
ments  that  are  "typically"  true,  but  which  are  not 
axiomatic.  Conceptually,  this  default  knowledge  consists 
of  rules  of  the  form  "if  nothing  has  been  asserted  or 
deduced  which  contradicts  X.  then  assume  X". 

We  will  first  discuss  why  the  Loom  architecture  in¬ 
cludes  a  Default  Box.  Then  we  will  examine  the  seman¬ 
tics  of  the  default  value  and  closed-worbi-assumption 
constructs.  Finally,  we  will  preview  what  the  operation 
of  a  non-monotonic  classifier  might  U>ok  like. 
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6.1.  The  Cue  for  a  Default  Box 

We  reject  the  idea  of  combining  assertion&l  and 
default  knowledge  into  a  single  *  non-monotonic  ABox". 
Such  a  strategy  would  contradict  a  philosophical  goal  of 
the  Loom  architecture:  We  wish  to  reserve  the  ABox  for 
statements  about  individuals,  and  to  extend  the 
representational  power  of  the  non-ABox  portion  of  the 
system  so  that  all  statements  about  "classes  of 
individuals"  can  be  represented  somewhere  else  other 
than  in  the  ABox.  The  nature  of  default  knowledge  is 
that  it  generally  makes  statements  about  classes  of  in¬ 
dividuals.  Thus,  we  must  consider  what  the  implications 
are  of  developing  yet  another  box. 

The  prerequisites  for  defining  a  new  "box"  in  the 
Loom  knowledge  representation  framework  are  that  (i) 
we  can  identify  a  significant  body  of  knowledge  which 
would  be  assigned  to  that  box,  and  (ii)  a  specialized 
reasoning  facility  must  exist  to  process  the  inferences  as¬ 
sociated  with  this  knowledge.  The  Loom  system  does  not 
yet  meet  these  requirements,  because  it  is  able  to  respond 
to  only  two  very  specialized  forms  of  default  knowledge  — 
it  includes  a  limited  treatment  of  default  values,  and  it 
recognizes  certain  closed-world  assumptions.  On  the 
other  hand,  we  already  have  some  idea  of  what  a  (much 
more  general)  non- monotonic  classifier  would  look  like. 
Its  behavior  is  sketched  below,  in  section  6.3.  Therefore, 
we  anticipate  that  both  prerequisites  will  be  met  in  a  fu¬ 
ture  version  of  Loom. 

6.2.  Default  Values  and 

Closed-World  Assumptions 

A  "default  value"  is  a  value  which  is  assigned  to  fill 
a  role/slot  for  some  individual  in  the  absence  of  any 
explicitly-asserted  (or  derived)  knowledge  about  that  role 
filler.  For  example,  in  our  Engines  and  Cars  KB,  the 
form 

(  defaults  (restriction  type-of-fuel 

(  vr  Casollne))) 


in  the  defconcept  declaration  for 

Internal-Coabustlon-Engine  declares  that  Gasoline  is  the 
default  value  for  the  role  typs-of-fuei.  If  for  some  con¬ 
stant  "x"  we  have  asserted 

(Internal -Coabustlon-Englne  x)  ,  and  we  have  made  no 
assertions  of  the  form  (type-of-fuel  z  f)  ,  then  the 
default  assumption  is  (type-of-fuel  x  Casollne)  . 

The  act  of  assigning  a  default  value  can  trigger  a 
re-classification  of  an  ABox  object.  For  example,  after 
making  the  assertion  (assert  Elephant  El),  the  process 
of  classifying  El  as  an  elephant  could  trigger  a  default 
assertion  color  El  Grey,  which  might  then  cause  El  to  be 
re-classified  as  a  grey-elephant  (if  such  a  concept  existed). 
We  have  yet  to  investigate  whether  default  values  may 
trigger  cycles  of  reclassifications,  and,  if  so,  how  the 
semantics  of  assigning  default  values  should  be  restricted 
to  prevent  such  cycles. 

The  Loom  representation  of  closed-world  assump¬ 
tions  is  another  example  where  we  can  elicit  useful 
default  behavior  in  the  absence  of  a  general-purpose  non¬ 
monotonic  classifier.  Each  ABox  knowledge  base  is  as¬ 
sumed  to  have  either  a  "closed- world"  or  an  "open- 
world"  interpretation.  "Open-world"  means  that  in  ad¬ 
dition  to  the  assertions  about  an  individual  that  are  ex¬ 
plicitly  stated  in  the  knowledge  base,  there  may  be  other 
relevant  assertions  which  have  been  left  unstated.  For 
example,  consider  the  Engines  and  Cars  KB  once  again. 
Suppose  we  make  the  assertions 

(assert  (Internal-Coabustlon-Engine  •) 

(Cylinder  cl)  (Cylinder  c2) 

(Cylinder  c3)  (Cylinder  c4) 

(cylinder  e  cl)  (cylinder  e  c2) 

(cylinder  e  c3)  (cylinder  e  c4)) 

Can  we  deduce  (4-Cyllnder-Englae  e)  ’  The  answer  is 
no  if  we  adopt  an  open-world  assumption,  because  the 
possibility  exists  that  there  arc  4  (or  12,  or  whatever) 
more  cylinders  which  arc  also  components  of  the  engine 
"e".  On  the  other  hand,  adopting  a  closed-world  as¬ 
sumption  would  allow  us  to  conclude  that  the  four 


cylinders  which  are  components  of  "e"  are  the  only  ones 
that  exist,  in  which  case  the  inference 
(4-Cyllndvr-Engln*  •)  is  valid. 

Loom  allows  one  to  declare  selective  "regions"  of 
closed-world  semantics  within  an  open-world  knowledge 
base:  The  declaration 

(d«fr«lation  M 

(  axioas  (  domain  D)) 

(defaults  closed-vorld-assuaptloa)) 

has  the  following  interpretation:  "If  "D(x)“  has  been  as¬ 
serted  (or  can  be  deduced)  for  some  x,  then  for  all  y, 
"M(x,  y)"  is  true  only  if  it  has  been  explicitly  asserted,  or 
can  be  derived."  The  defrelation  declaration  for  the 
relation  cylinder  in  the  Engines  and  Cars  KB  includes 
such  a  closed-world  assumption.  This  assumption  allows 
the  classifier  to  count  instances  of  the  cylinder  relation 
when  attempting  to  recognize  an  object  as  an  instance  of 
the  concept  4-Cylinder-Engine. 

8.3.  Preview  of  a  Non-Monotonic  Classifier 

A  non-monotonic  classifier  has  not  yet  been 
developed  for  the  Loom  architecture.  We  provide  here  a 
preview-  of  w  hat  its  behavior  will  be  like  if  and  when  it  is 
constructed,  with  the  intention  of  stimulating  the 
demand  for  such  a  reasoner.  Our  example  provides  an  il¬ 
lustration  of  how  a  classic  problem  in  non-monotonic 
reasoning  can  he  modeled  by  the  Loom  language. 

In  the  process  of  claasifying/recognizing  an  object 
"x",  a  non-monotonic  classifier  will  reference  both  ex¬ 
plicitly  declared  knowledge  and  default  knowledge  about 
“x".  and  hence  may  deduce  classifications  which  are 
t  :ised  on  default  assumptions.  As  is  the  case  with  UBox 
classification,  the  classifier  may  acquire  additional  infor¬ 
mation  about  "x"  in  the  midst  of  the  classification 
process.  The  possibility  arises  that  the  "acquired* 
knowledge  will  contradict  one  (or  more)  of  the  default  as¬ 
sumption'  In  this  case,  the  classifier  must  retract  any 
.ussificaiiuns  it  h:ts  already  made  which  were  based  on 
'  licse  non-vali  I  assumptions. 
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Consider  the  Birds  KB  in  Figure  A-5.  Suppose  we 
have  made  the  assertion 
(assert  (Penguin  Tveety)) 

The  classifier  may  first  deduce  (Bird  Tveety)  ,  then 
pick-up  the  attached  default  implication  and  assume 
(Flylng-Aniaal  Tveety)  ,  and  then  deduce 
(Flylng-Blrd  Tveety)  .  Next,  it  may  deduce 
(Non-Flying-Aniaal  Tveety)  from  the  definition  of 
Penguin,  and  then  discover  that  Flying-Anlaal  and 
Mon-Flying-Aniaal  are  disjoint.  At  this  point,  it  must 
retract  the  earlier  deductions  (Flying-Anlaal  Tveety) 
and  (Flylng-Blrd  Tveety)  . 

7,  Conclusion 

The  Loom  language  introduces  new  expressivity  and 
some  new  and  powerful  forms  of  inference  into  the  KL- 
ONE  paradigm  for  knowledge  representation.  The  most 
significant  achievement  is  the  formulation  of  the  UBox, 
which  allows  universal  knowledge  to  be  defined  and 
reasoned  about  independently  of  the  terminological 
knowledge.  The  UBox  solves  a  long-standing  problem  of 
how  to  represent  necessary  and  sufficient  conditions,  and 
provides  a  way  for  a  user  to  introduce  cyclic  references 
into  a  knowledge  base  without  derailing  the  classifier. 

Looking  towards  the  future,  we  have  described  the 
behavior  of  a  Default  Box,  indicating  how  a  classifier 
might  be  extended  to  perform  non-monotonic  classifica¬ 
tions.  Collectively,  our  results  suggest  that  we  have 
taken  another  step  in  an  ongoing  evolution  of  knowledge 
representation  systems,  wherein  increasing  numbers  of 
specialized  forms  of  reasoning  can  be  organized  within  a 
principled  knowledge  representation  framework. 
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A.  Knowledge  Bases 


Engines  and  Cars  Knowledge  Base 

(d«f relation  bas-coaponent  (prlsltlve  (  lnverae-of  cosponent-of)) 

(defrelatlon  cosponent-of  primitive) 

(defconcept  Horse-Power  prlaltlve) 

(defrelatlon  horse-power  (:range  Horse-Power)) 

(defconcept  Fuel  prlsltlve) 

(defrelatlon  type-of-fuel  (: range  Fuel)) 

(defconcept  Gasoline  :prlsltlve  (specializes  Fuel)) 

(defconcept  Dlesel-011  prlsltlve  (specializes  Fuel)) 

. . .  Engines 

(defconcept  Engine  prlsltlve 

(  axloas  (restriction  type-of-fuel  (nuaber  1)) 

(  restriction  horse-power  (:nusber  1)))) 

(defconcept  Cylinder  prlsltlve) 

(defrelatlon  cylinders  (specializes  has-cosponent)  (range  Cylinder) 

(  defaults  closed-world-aesuaptlon}) 

(defconcept  Internal-Cosbustlon-Englne  (specializes  Engine) 

(restriction  cylinders  (:sln  1)) 

(  defaults 

(  restriction  type-of-fuel  (:vr  Gasoline)))) 

(defconcept  4-Cylinder-Engine  (specializes  Engine) 

(  restriction  cylinders  (: nuaber  4))) 

. . .  Diesel-Engines 

(defconcept  Glow-Plug  prlsltlve) 

(defrelatlon  cospression-ratio  prlsltlve 

(  ax  loss  (  doaain  Internal-Cosbustlon-Englne)  (range  Integer))) 

(.defconcept  Dlesel-Oll-Englne  ((Specializes  Engine) 

(  restriction  type-of-fuel  (:vr  Dlesel-011)) 

(  azloss 

(  laplles  Dlesel-Englne))) 

(defconcept  Thlng-with-Glow-Plugs 

(restriction  (vrdlff  has-cosponent  Glow-Plug)  (  sin  1)) 

(  azloss 

(  laplles  Dlesel-Englne))) 

(defconcept  Very-High-Coapresslon-Englne 

(  constraint  greater-than  (cospression-ratio)  IS) 

(  azloss 

(  laplles  Dlesel-Englne))) 

(defconcept  Dlesel-Englne  prlsltlve 

(  special l zee  Internal-Cosbustlon-Englne  Dlesel-Oll-Englne 

Thlng-with-Glow-Plugs  Very-Hlgh-Cospression-Engine) ) 
(defconcept  Battery-Pc  ered-Englne  prlsltlve  (  specializes  Engine)) 

.  Care 

(defconcept  Vehicle  prlsltlve) 
def  concept  Motor-Vehicle  (  specializes  Vehicle) 

(  restriction  (  vrdlff  has-cosponent  Engine)  (  nuaber  l))) 

.defconcept  Battery-powered-Vehicle  (  specializes  uotor-Veblc le) 

(  restriction  (  vrdlff  has-cosponent  Engine)  (  vr  Battery -Power  ed  -  Er.gi  ne ; 
(  azloss  (  laplles  Car))) 
defrelatlon  occupants  prlsltlve  (  range  Huaan)) 
def concept  2-Person~Veblcle  (  specializes  Vehicle) 

(  restriction  occupants  (  sax  2))) 
defconcept  Car  prlsltlve  (  specializes  Vehicle) 
ailcss 

izplles  Motor -Vehlc le) ) ) 

fefcjr.-ept  2  -  Pe  r  sor.  -  Car  (  specialties  Car  2  ■  Person-Vehl  cle) ' 


Figure  A- 1:  Engine?  and  Car? 


Numeric  Comparison  Knowledge  Bases 


;  Numeric  Comparison  Predicates 

(defrelatlon  numeric-comparison  primitive  (specializes  Compute-Relation) 

( : asloas 

(doaaln  Real-Number)  (: range  Real-Nuaber) 

(covering  greater-or-equal  less-or-equal))) 

(defrelatlon  greater-tban  primitive  (specializes  greater-or-equal  not-equai) 
( : annotation 

(  aeabersblp- test  (laabda  (doaaln  range)  (>  doaaln  range))))) 

(defrelatlon  less-tban  primitive  (  specializes  lsas-or-equal  not-equal) 

( : annotation 

( :a*ab*rsblp-t*st  (laabda  (doaaln  range)  (<  doaaln  range))))) 

(defrelatlon  equal  primitive  (specializes  greater-or-equal  less-or-equal) 

( : annotation 

(  aeabereblp-test  (laabda  (doaaln  range)  (eql  doaaln  range))))) 
(defrelatlon  not-equal  primitive  (specializes  nuaerlc-conparlson) 

(  azloas 

(disjoint-covering  greater-tban  less-tban))) 

(defrelatlon  greater-or-equal  prlaltlve  (specializes  nuaeric-eonparlsor.; 

(  axloas 

(  disjoint-covering  equal  greater-than) ) ) 

(defrelatlon  less-or-equal  prlaltlve  (  specializes  numeric-comparison) 

(  asloas 

(  dls joint-covering  equal  less-tban))) 

Figure  A-2:  Numeric  Comparison 


Seta  and  Intervals  Knowledge  Base 


.  .  .  Set 

(defconcept  Anlaal  prlaltlve) 

(defset  Ses  (  values  Male  Feaale)  (  partitions  Anlaal)) 

. . .  Navy  Rankings 

(defconcept  Navy-Person  prlaltlve) 

(defconcept  Military-Rank  prlaltlve) 

(defrelatlon  Rank  (  range  Mllltarjr-Rank) ) 

(defrelatlon  Naval-Rank  prlaltlve  (  specializes  Rank) 

(  asloas  (  doaaln  Navy-Person)  (  range  Naval -Rank) ) ) 

(deflnterval  Naval-Rank  prlaltlve  (  specializes  Military-Rank) 

(  values  Seaman-Recruit  Seaman- Apprentice  Seaaan  Petty-Off  leer -Third-Class 

Petty-Off lcer-Second-Class  Petty-Off lcer-Flrsl-Clase  Cblef-Petty-Of fleer 
Senior -Chief -Petty-Of fleer  Mas ter -Chief -Petty-Of fleer 
Ensign  Lleutenant-Junlor-Crade  Lieutenant  Lleutenant-Coaaander 
Coaaander  Captain  Coaaodore  Rear-Adalral  Vice-Admiral  Admiral) 

(  partitions  Navy-Person  (  sufflz  nil))) 

(defset  Naval-Officer-Rank  (  specializes  Naval-Rank)  (  values  [Ensign  Admiral;)) 

. . .  Numbers 

(defconcept  Real-Nuaber  prlaltlve 
(  annotation 

(  aeabersbip-teet  (laabda  (self)  (nuaberp  self))))) 

(deflnterval  Integer  prlaltlve  (  specializes  Real-Nuaber) 

(  values  [-INFINITY  INFINITY]) 

(  annotation 

(  membership-test  (laabda  (self)  (integerp  self))) 

(  predecessor  fn  (laabda  (self)  (l-  self))) 

(  successor  fn  (laabda  (self)  (!•  self))))) 

(deflnterval  Natural -Number  (  specializes  Integer)  (  values  (0  INFINITY 
(deflnterval  Pot  1 ttve- Integer  (  specializes  Integer)  (  value*  .1  INFINITY 
(deflnterval  Non  Negative- Integer  (  specialize*  Integer) 
value*  i  INFINITY  1  [I  INFINITY  ') 


Figure  A  -  3 :  '•  •-  ml  I:  ■  i 


#3 


Familial  Relation!  Knowledge  Base 


. .  .  Person 
(defconcept  Person 


prlaltlve) 


.  .  .  Faalllsl  Relations 

(def relation  parent  prlaltlve 

(  aiioas  <  doaaln  Person)  (range  Person))) 

(def relation  fatber  (  specializes  parent)  (range  Male)) 

(def relation  grandparent  ( : coapoeltlon-of  parent  parent)) 

(defrelatlon  grandfather  (coapoeltlon-of  parent  fatber)) 

(def relation  anceetor  (cloeurs-of  parent)) 

(defrelatlon  child  (  mverse-of  parent)) 

(defrelatlon  sibling  ( : coaposltlon-of  parent  child)  (  specializes  not- equal)) 
(defrelatlon  brother  (  specializes  sibling)  (: range  sale)) 


Figure  A-4:  Familial  Relations 


Birds  Knowledge  Base 


(defconcept  Anlaal  prlaltlve 

(  aiioas  (  die  joint-covering  Flying-Anlaal  Non-Flylng-Anlaal))) 
(defconcept  Flying-Anlaal  prlaltlve  (specializes  Anlaal)) 
(defconcept  Mon  Flying-Anlaal  prlaltlve  (specializes  Anlaal)) 

(defconcept  Bird  prlaltlve  (  specializes  Anlaal) 

(defaults  (  lsplies  Flying-Anlaal))) 

(defconcept  Flying-Bird  (  specializes  Bird  Flying-Anlaal)) 

(defconcept  Penguin  prlaltlve  (  specializes  Bird  Non-Flylng-Anlaal ) ) 


Figure  A-5:  Birds 


H.  Semantics  of  Term-Defining  Constructs 


Loom  Expression, 
e 

(defconcept  (  epecialiies  Cj  Cj)) 

(defconcept  (  restriction  M  (vr  C))) 
(defconcept  (  restriction  M  (min  a))) 
(defconcept  (  restriction  M  (me  a))) 
(defconcept  (  constraint  CR  (Rj  R,)  (Sj  s,))) 

(virft oiicrpi  (  conairaiol  CR  (R| 

(drfrfiti.on  (  sp«<itlis«s  M|  M^)) 

I drfrnation  (  r*ng?  C)) 

'drfrriAtion  (  invtrtMf  M)) 

'■Jefrr|»tmn  !  clnaure-of  M ) > 

{  <ompo*»iion-o(  M|  M,» 


Scmanucs  of  t, 

M 

x*  Bc,D(*)aBC,B(*) 

x*  Vp(BMD(s,p)  -  QCU(sr)) 

Ax  3  s  dtisfiitef  jr(  a,  BMI)(x.  pt) 

Ax  |  a  +  l  firlnul  ((M'Jlx,^) 

Ax  Vn.idfRjflsBRjIKi.pjA 

BSiD«Bs,H(x. »))  -  JCRKP.X)) 

x«  ¥»(iiR,MR,i!(*.»)  -  Ucrii(m.  »)) 

x*.»  ffM,!!(x.  p)  A  [[M^fx.  p) 

x*  »  QCQCsr) 

x*  m  3M0(».  *) 
x*  »  *(*.») 
x*»  BMjiXIMjEix.*) 


